Instruction filtering

ABSTRACT

Embodiments relate to instruction filtering. An aspect includes a computer-implemented method for instruction filtering. The method includes detecting, by a processor, a tracked instruction in an instruction stream, and storing an instruction address of the tracked instruction in a tracking array based on detecting and executing the tracked instruction. The method also includes accessing the tracking array based on an address of instruction data of a subsequently fetched instruction to locate the instruction address of the tracked instruction in the tracking array as an indication of the tracked instruction. The method further includes marking, by the processor, instruction text of the subsequently fetched instruction to indicate that the subsequently fetched instruction is a previously executed tracked instruction based on the indication of the tracked instruction from the tracking array. The method additionally includes preventing an action of a tracked instruction logic block based on detecting the marked instruction text.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a continuation application that claims the benefit of U.S.patent application Ser. No. 13/523,170 filed Jun. 14, 2012, the contentsof which are incorporated by reference herein in their entirety.

BACKGROUND

The present invention relates generally to computer processing systems,and more specifically, to instruction filtering.

An instruction pipeline in a computer processor improves instructionexecution throughput by processing instructions using a number ofpipeline stages, where multiple stages can act on different instructionsof an instruction stream in parallel. A conditional branch instructionin an instruction stream may result in a pipeline stall if the processorwaits until the conditional branch instruction is resolved in anexecution stage in the pipeline before fetching a next instruction in aninstruction fetching stage for the pipeline. A branch predictor mayattempt to guess whether a conditional branch will be taken or not.Branch target prediction attempts to guess, based on prior executionresult, a target of a taken conditional or unconditional branch beforeit is computed by decoding and executing the instruction itself. Abranch target may be a computed address based on an offset and/or anindirect reference through a register.

A branch target buffer (BTB) is used to predict the target of apredicted taken branch instruction based on the address of the branchinstruction. Predicting the target of the branch instruction can preventpipeline stalls by not waiting for the branch instruction to reach theexecution stage of the pipeline to compute the branch target address. Byperforming branch target prediction, the branch's target instructiondecode may be performed in the same cycle or the cycle after the branchinstruction instead of having multiple bubble/empty cycles between thebranch instruction and the target of the predicted taken branchinstruction. Other branch prediction components that may be included inthe BTB or implemented separately include, but are not limited to, abranch history table and a pattern history table for predicting thedirection of the branch. A branch history table can predict thedirection of a branch (taken vs. not taken) as a function of the branchaddress. A pattern history table can assist with direction prediction byassociating a direction prediction for the given branch with the path ofbranches that was encountered in reaching the given branch that is to bepredicted.

Instructions supporting branch prediction are examples of non-functionalaccelerator type instructions that are not critical to correct programflow but can enhance program flow. Repeated execution of certainnon-functional accelerator type instructions can impact overallprocessing throughput and the effectiveness of accelerator functions.

SUMMARY

Exemplary embodiments include a computer-implemented method forinstruction filtering. The method includes detecting, by a processor, atracked instruction in an instruction stream, and storing an instructionaddress of the tracked instruction in a tracking array based ondetecting and executing the tracked instruction. The method alsoincludes accessing the tracking array based on an address of instructiondata of a subsequently fetched instruction to locate the instructionaddress of the tracked instruction in the tracking array as anindication of the tracked instruction. The method further includesmarking, by the processor, instruction text of the subsequently fetchedinstruction to indicate that the subsequently fetched instruction is apreviously executed tracked instruction based on the indication of thetracked instruction from the tracking array. The method additionallyincludes preventing an action of a tracked instruction logic block basedon detecting the marked instruction text.

Additional exemplary embodiments include a computer program product forinstruction filtering. The computer program product includes a tangiblestorage medium readable by a processing circuit and storing instructionsfor execution by the processing circuit for performing a method. Themethod includes detecting, by the processing circuit, a trackedinstruction in an instruction stream, and storing an instruction addressof the tracked instruction in a tracking array based on detecting andexecuting the tracked instruction. The method also includes accessingthe tracking array based on an address of instruction data of asubsequently fetched instruction to locate the instruction address ofthe tracked instruction in the tracking array as an indication of thetracked instruction. The method further includes marking, by theprocessing circuit, instruction text of the subsequently fetchedinstruction to indicate that the subsequently fetched instruction is apreviously executed tracked instruction based on the indication of thetracked instruction from the tracking array. An action of a trackedinstruction logic block is prevented based on detecting the markedinstruction text.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The subject matter which is regarded as embodiments is particularlypointed out and distinctly claimed in the claims at the conclusion ofthe specification. The forgoing and other features, and advantages ofthe embodiments are apparent from the following detailed descriptiontaken in conjunction with the accompanying drawings in which:

FIG. 1 depicts a processing system according to an embodiment;

FIG. 2 depicts branch prediction logic according to an embodiment;

FIG. 3 depicts a branch target buffer entry according to an embodiment;

FIG. 4 depicts branch prediction logic according to another embodiment;

FIG. 5 is a flowchart illustrating a process of instruction filteringaccording to an embodiment;

FIG. 6 is a flowchart illustrating a process of handling preloading ofmulti-target branch types according to an embodiment;

FIG. 7 depicts a computing system according to an embodiment; and

FIG. 8 depicts a computer-readable medium according to an embodiment.

DETAILED DESCRIPTION

Exemplary embodiments provide instruction filtering. Non-functionalaccelerator type instructions are not critical to correct program flowbut can enhance program flow. A branch prediction preload instruction isan example of a non-functional accelerator type instruction that canpreload a branch predictor with a branch prediction. Without filtering,repeated execution of the branch preload instruction continuallyinstalls the preloaded branch prediction into the branch predictor.These reinstallations create redundant, equivalent branch predictions inthe branch predictor. Functionally, redundant predictions do not affectmicroprocessor data integrity; however, redundant predictions reduce theoverall number of unique predicted branches that can be stored in thebranch predictor. Redundant predictions can impact overall performance,as each preload may cause the eviction of other, unique branchpredictions. Exemplary embodiments perform instruction filtering byleveraging a table that is synchronous with an instruction cache so asto perform actions associated with a tracked instruction a single time.Although embodiments are described in reference to branch predictionpreload instructions, it will be appreciated that instruction filteringcan be performed for any number of other non-functional accelerator typeinstructions.

FIG. 1 depicts a block diagram a processing system 100 according to anembodiment. The processing system 100 includes program fetch control101, a tracking array 102, an instruction cache 103, instruction decodeand marking logic 104, an execution unit 105, memory 106, and branchprediction logic (BPL) 110. The processing system 100 can be embodied ina single processor or processing circuit of a computer, or can bedistributed between multiple components in a computer system. Forexample, memory 106 can be internal or external to a processor of theprocessing system 100. The memory 106 may include any type of volatileor non-volatile memory, including one or more levels of cache memory.Instructions and data can be stored in memory 106, and the instructioncache 103 may access instructions in memory 106 and store theinstructions to be fetched. A data cache (not depicted) may also beincluded in the processing system 100.

In the example of FIG. 1, instruction tracking and filtering isperformed on branch prediction preload instructions as the trackedinstructions. A branch prediction preload instruction can specify branchprediction information, such as a predicted branch instruction address,a predicted branch's target address, a branch type, and may includeadditional information. The branch prediction logic 110 is an example ofa tracked instruction logic block. Accordingly, the tracking array 102is also referred to as a branch prediction preload tracking array. Thebranch prediction logic 110 stores branch predictions in a number ofentries that can be organized as congruence classes of sets of entries.An example congruence class includes entry A 111, entry B 112, entry C113, and entry D 114. When a branch prediction preload instruction isfirst executed at execution unit 105, a prefetch of the instructioncache 103 may be initiated to provide the instruction cache 103 a headstart on preloading the predicted branch's target instruction streaminto the instruction cache 103 if it is not there already. The branchprediction information is passed to the branch prediction logic 110 tobe stored. The instruction address of the branch, its direction andaddress of its target are stored into the least recently used (LRU)entry (one of entry A 111, entry B 112, entry C 113, entry D114) of aparticular congruence class, accessed using a subset of the instructionaddress of the branch instruction, after the branch prediction preloadinstruction is executed. Once the branch prediction information isstored, it is accessible by the branch prediction logic 110, such thatthe associated branch can be dynamically predicted via the program fetchcontrol logic 101 in the expected direction when the predicted branchinstruction is executed at execution unit 105. Prefetching using thepredicted target address of the branch enables the instruction cache 103to have the branch's target instruction stream ready at branch executiontime.

Upon encountering the same branch prediction preload instruction two ormore times (for example, within a loop or a frequently calledsubroutine), rather than simply installing a redundantly executed branchprediction preload instruction's information into the next LRU locationof a particular congruence class (one of entry A 111, entry B 112, entryC 113, entry D114), instruction filtering is performed. Withoutinstruction filtering, if the congruence class was fully populated withuseful predictions, the LRU would remove a useful prediction and installa redundant preload entry instead. The overwritten branch predictioncould no longer be dynamically predicted, which could potentially resultin throughput penalties encountered with branch mispredictions, delayedtaken branch redirect instruction stream, and no cache prefetching as afunction of a BTB taken prediction. Exemplary embodiments use thetracking array 102 to record execution of tracked instructions and marksubsequent instances of the tracked instruction using the instructiondecode and marking logic 104 to prevent an action of a trackedinstruction logic block (e.g., branch prediction logic 110) based ondetecting the marked instruction. For example, if a predicted branch ispreloaded based on a branch prediction preload instruction, thensubsequent execution of the same branch prediction preload instructiondoes not install a new, redundant branch prediction into the branchprediction logic 110.

FIG. 2 depicts an example of the BPL 110 of FIG. 1 in greater detail.The example BPL 110 of FIG. 2 includes a branch predictor 200 with abranch target buffer (BTB) 204 and a victim entries table 208. The BTB204 and victim entries table 208 may both be set associative, includingmultiple sets (columns) of BTB entries. The BPL 110 also includes branchprediction and eviction logic 202 and hit detection logic 212. Thebranch prediction and eviction logic 202 can control access and updatesof BTB entries in the BTB 204 and victim entries table 208, as well asmovement of BTB entries between the BTB 204 and victim entries table208. In an exemplary embodiment, BTB 204 is a primary BTB and victimentries table 208 is a table of BTB entries removed from the primaryBTB. In the example of FIG. 2, BTB installs are performed primarilythrough BTB 204; however, in other embodiments, BTB installs can beperformed relative to other BTB structures, such as direct installationinto another BTB (not depicted) or victim entries table 208.

A generic example of a BTB entry is depicted in FIG. 3 as BTB entry 300(also referred to as entry 300), which includes a branch tag address302, a branch type field 304, a predicted target address 306, and abranch direction 308. With continued reference to FIGS. 1-3, the branchtag address 302 is used to locate an entry within a BTB row 310, whereeach of the BTB 204 and victim entries table 208 of FIG. 2 can includemultiple BTB rows 312 and multiple set associative BTB entries per BTBrow 310. Each BTB row 310 is also referred to as a congruence class. Theexample row 310 includes entry A 111, entry B 112, entry C 113, andentry D 114 of FIG. 1, where each entry 111-114 is a different column orset 314. An LRU identifier (LRU) can also be tracked to assist indetermining which BTB entry 300 was least recently used forremoval/replacement of entries. The branch type field 304 can bepopulated on a preload of a branch instruction to provide additionalinformation about a predicted branch. For a non-preload branch, thebranch type field 304 is also populated with a value, for example, avalue representing the branch type associated with the type of branchthat was installed or a pre-defined default. The branch direction 308can indicate whether the associated branch is to be guessed/predictedtaken or not taken. Additional fields may also be included in each BTBentry 300.

In an exemplary embodiment, an address of an instruction fetch by theprogram fetch control 101 of FIG. 1 is used as a search address toaccess the BPL 110 and predict any associated branch and, if taken, thenalso predict the branch's target address. BTB 204 can contain primaryBTB entries of interest for predicting branch target addresses. Thevictim entries 208 can include BTB entries that have been recentlyevicted from the BTB 204 by the branch prediction and eviction logic202. When a BTB entry is evicted from BTB 204, it is written as a BTBvictim to the victim entries 208. Eviction can be based on monitoringfor least recently used BTB entries and determining which locations inthe BTB 204 to overwrite based on receiving an installation request froman install source, such as a surprise install, a branch predictionpreload instruction, a victim hit, or other BTBs. A surprise install isbased on a branch from a branch instruction that was not predicted bythe hit detection logic 212 but was detected as a branch only by thedecode and marking logic 104 of FIG. 1. The victim entries 208 and theBTB 204 can both provide input to hit logic 212 to determine whether amatch or “hit” is located based on the search address. If a match isfound, the hit logic 212 outputs a predicted target address. If thematch was from the victim entries 208 (a victim hit), the correspondingBTB entry can be returned to the BTB 204 as a victim install, such thatthe most recent and relevant branch target predictions are maintained inthe BTB 204. The branch prediction and eviction logic 202 may alsomanage other branch prediction functions/predictors.

FIG. 4 depicts an alternate embodiment of the BPL 110 of FIG. 1 ingreater detail as BPL 110′. The example BPL 110′ of FIG. 4 is similar tothe BPL 110 of FIG. 2 and includes a branch predictor 400 with a branchtarget buffer (BTB) 404 and a branch target buffer preload table (BTBP)408. The BTB 404 and BTBP 408 may both be set associative, includingmultiple sets (columns) of BTB entries. The BPL 110′ also includesbranch prediction and eviction logic 402 and hit detection logic 412.The branch prediction and eviction logic 402 can control access andupdates of BTB entries in the BTB 404 and BTBP 408, as well as movementof BTB entries between the BTB 404 and BTBP 408. In an exemplaryembodiment, BTB installs are performed primarily through BTBP 408, withBTB entries passed from BTBP 408 to BTB 404 based on detecting a BTBPhit in the BTBP 408. Each entry in the BTB 404 and BTBP 408 can also beformatted as the BTB entry 300 of FIG. 3.

In an exemplary embodiment, an address of a branch instruction fetchedby the program fetch control 101 of FIG. 1 is used as a search addressto access the BPL 110′ and predict a branch target address. When lookingfor branch predictions, both the BTB 404 and BTBP 408 are read. Eitherone can provide a branch prediction if it contains an entry with abranch address tag 302 matching the search address. The BTBP 408 and theBTB 404 both provide input to hit detection logic 412 to determinewhether a match or “hit” is located based on the search address. If amatch is found, the hit detection logic 412 outputs a predicted targetaddress. If the match was from the BTBP 408, a corresponding matchingentry can be installed to the BTB 404 as a BTBP hit to overwrite a BTBvictim entry in the BTB 404, such that the most recent and relevantbranch target predictions are maintained in the BTB 404. Similar to theBTB 204 of FIG. 2, the BTBP 408 supports installation requests from avariety of install sources, such as a surprise install, a branchprediction preload instruction, a victim hit, or other BTBs.

Turning now to FIG. 5, a process 500 of instruction filtering will nowbe described in an exemplary embodiment. The process 500 is described inreference to FIGS. 1-4 and can be implemented by the processing system100 of FIG. 1 using the BPL 110 or 110′ of FIGS. 2 and 4.

At block 502, a tracked instruction is detected in an instructionstream. A branch prediction preload instruction is an example of atracked instruction. At block 504, an instruction address of the trackedinstruction is stored in the tracking array 102, given it is not alreadyin the array, based on detecting and executing the tracked instruction.For example, whenever a branch prediction preload instruction isencountered and executed at execution unit 105, its instruction addressis recorded in the tracking array 102. The tracking array 102 can beused to track the instruction addresses of branch prediction preloadinstructions or other tracked instructions.

At block 506, the tracking array 102 is accessed based on an address ofinstruction data of a subsequently fetched instruction to locate theinstruction address of the tracked instruction in the tracking array 102as an indication of the tracked instruction. Upon every fetch requestmade by the program fetch control 101, the address of the instructiondata being fetched can be used to access the tracking array 102 inparallel with the instruction cache 103.

At block 508, instruction text of the subsequently fetched instructionis marked to indicate that the subsequently fetched instruction is apreviously executed tracked instruction based on the indication of thetracked instruction from the tracking array 102. Marking may beperformed at the instruction decode and marking logic 104 to provide anindication to the execution unit 105 that the tracked instruction wasalready executed and thus, already performed an associated action, suchas installing a preloaded branch prediction in branch predictor 200,400. At block 510, an action of the tracked instruction logic block isprevented based on detecting the marked instruction text. For example,when the marked branch prediction preload instruction is executed atexecution unit 105, the mark indicates to the BPL 110 not to install thepreloaded branch prediction into the LRU location, effectively makingthe branch prediction preload instruction a no-op instruction. The LRUentry is preserved.

Entries are removed from the tracking array 102 as newer entries evictolder ones. If removal/replacement of entries in the tracking array 102is based only on addresses, problems can arise where multiple branchesalias to the same BTB location. In an embodiment, entries can beselected to remove from the tracking array 102 randomly based ondetecting tracked instructions. Randomly removing entries from thetracking array 102 can reduce performance impacts associated withaddress aliasing and increase the probability that actions of preloadingwill take place when beneficial to performance. Removal of an entry canbe performed by setting an associated validity bit for the entry toinvalid and optionally identifying the entry as LRU.

As previously described, a branch prediction preload instruction enablessoftware-driven preloading of the BTB 204 of FIG. 2 or the BTBP 408 ofFIG. 4 with a branch prediction at a given address with a given targetaddress. Instruction filtering prevents the same branch prediction frombeing redundantly installed in the BTB 204 or the BTBP 408. However,multi-target branch type instructions should not be filtered such thatonly a single preload is performed, since separate preloads mayreference different targets from the same instruction address. Amulti-target branch is a branch instruction that can have differenttarget addresses from the same instruction address. For example, abranch instruction that functions as a return branch that is callablefrom different software modules can exhibit different return addresseswhen returning to each calling module. To allow for multi-targetbranches to be preloaded as the target address changes, modification ofBTB entries can be supported in the instruction filtering of BPL 110,110′. Typical installation to branch predictors 200, 400 is based on LRUposition; however, the LRU position changes over time. Exemplaryembodiments install multi-target branches into a predetermined set ofthe branch predictor 200, 400 rather than the LRU position as furtherdescribed herein.

Process 600 of FIG. 6 depicts an example process for handling preloadingof multi-target branch types and can be implemented by BPL 110 of FIG. 2and/or BPL 110′ of FIG. 4. At block 602, a branch type of a to bepreloaded branch prediction identified in a branch prediction preloadinstruction is checked. Branch type information can be determined from amask field of the branch prediction preload instruction. At block 604,based on determining that the branch type is a multi-target branch,installation of the to be preloaded branch prediction is forced into apredetermined set of the branch predictor 200, 400 of FIGS. 2 and 4,regardless of an LRU position of the branch predictor 200, 400. Thus,rather than preventing all installations to branch predictors 200, 400,the BPL 110, 110′ can prevent LRU-position based installation andinstead force installation to a predetermined set for multi-targetbranches. Similar to other branch prediction installs, the entryresulting from installation of a preloaded multi-target branchprediction is made most recently used (MRU) to prevent early replacementby a non-multi-target branch install. Using a predetermined set formulti-target branch entries enables modification of existing entries asthe branch target address changes. The predetermined set of the branchpredictor is determined based on one or more of: a predicted branchinstruction address and a thread identifier. For example, when theprocessing system 100 is implemented in a simultaneous multithreadingprocessor, bits used to identify a thread number can be used to select aset 314 and/or used in combination with prediction branch address bitsto select a set 314.

At block 606, movement of an entry in the branch predictor 200, 400 iscontrolled based on determining that the branch type of the entry is amulti-target branch. For example, in branch predictor 400, installs arefirst done into the BTBP 408 and then entries are moved into the BTB 404upon a future prediction from the BTBP 408. Where a branch preload of amulti-target branch is installed into the BTBP 408, movement ofmulti-target branch entries from the BTBP 408 to the BTB 404 is blocked.Blocking movement prevents a potential mismatch scenario where an entrywith a first target address is moved to the BTB 404 and removed from theBTBP 408 followed by installation of a new entry for the same branchinstruction having a different target in the BTBP 408.

At block 608, aliasing conditions in the branch predictor 200, 400 arehandled by the BPL 110, 110′. For the example of FIG. 4, an alias withthe BTB 404 and BTBP 408 may exist such that a given location where abranch is predicted, a branch does not exist, and a differentinstruction, such as a load instruction exists at the given addressinstead. In this example, branch prediction and eviction logic 402 ofFIG. 4 can determine that a branch alias exists at a location in theBTBP 408 where a multi-target branch is predicted but does not exist.The branch prediction and eviction logic 402 can store an indication ofthe branch alias for the location in the BTBP 408. The branch predictionand eviction logic 402 invalidates an entry at the location in the BTBP408 based on detecting the stored indication of the branch alias on anext multi-target branch prediction. The stored indication of the branchalias is also cleared upon the invalidation of the entry.

FIG. 7 depicts a block diagram of a system 700 for instruction filteringin a processor 705. The methods described herein can be implemented inhardware, software (e.g., firmware), or a combination thereof. In anexemplary embodiment, the methods described herein are implemented inhardware as part of the microprocessor of a special or general-purposedigital computer, such as a personal computer, workstation,minicomputer, or mainframe computer. The system 700 therefore includesgeneral-purpose computer 701 as illustrated in FIG. 7.

In an exemplary embodiment, in terms of hardware architecture, as shownin FIG. 7, the computer 701 includes a processor 705 which is aprocessing circuit that includes the processing system 100 of FIG. 1 ora portion thereof. The computer 701 further includes memory 710 coupledto a memory controller 715, and one or more input and/or output (I/O)devices 740, 745 (or peripherals) that are communicatively coupled via alocal input/output controller 735. The input/output controller 735 canbe, for example but not limited to, one or more buses or other wired orwireless connections, as is known in the art. The input/outputcontroller 735 may have additional elements, which are omitted forsimplicity, such as controllers, buffers (caches), drivers, repeaters,and receivers, to enable communications. Further, the local interfacemay include address, control, and/or data connections to enableappropriate communications among the aforementioned components.

The processor 705 is a hardware device for executing software,particularly that stored in storage 720, such as cache storage, ormemory 710. The processor 705 can be any custom made or commerciallyavailable processor, a central processing unit (CPU), an auxiliaryprocessor among several processors associated with the computer 701, asemiconductor based microprocessor (in the form of a microchip or chipset), a macroprocessor, or generally any device for executinginstructions.

The memory 710 can include any one or combination of volatile memoryelements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM,etc.)) and nonvolatile memory elements (e.g., ROM, erasable programmableread only memory (EPROM), electronically erasable programmable read onlymemory (EEPROM), programmable read only memory (PROM), tape, compactdisc read only memory (CD-ROM), disk, diskette, cartridge, cassette orthe like, etc.). Moreover, the memory 710 may incorporate electronic,magnetic, optical, and/or other types of storage media. Note that thememory 710 can have a distributed architecture, where various componentsare situated remote from one another, but can be accessed by theprocessor 705.

The instructions in memory 710 may include one or more separateprograms, each of which includes an ordered listing of executableinstructions for implementing logical functions. In the example of FIG.7, the instructions in the memory 710 a suitable operating system (OS)711. The operating system 711 essentially controls the execution ofother computer programs and provides scheduling, input-output control,file and data management, memory management, and communication controland related services.

In an exemplary embodiment, a conventional keyboard 750 and mouse 755can be coupled to the input/output controller 735. Other output devicessuch as the I/O devices 740, 745 may include input devices, for examplebut not limited to a printer, a scanner, microphone, and the like.Finally, the I/O devices 740, 745 may further include devices thatcommunicate both inputs and outputs, for instance but not limited to, anetwork interface card (NIC) or modulator/demodulator (for accessingother files, devices, systems, or a network), a radio frequency (RF) orother transceiver, a telephonic interface, a bridge, a router, and thelike. The system 700 can further include a display controller 725coupled to a display 730. In an exemplary embodiment, the system 700 canfurther include a network interface 760 for coupling to a network 765.The network 765 can be an IP-based network for communication between thecomputer 701 and any external server, client and the like via abroadband connection. The network 765 transmits and receives databetween the computer 701 and external systems. In an exemplaryembodiment, network 765 can be a managed IP network administered by aservice provider. The network 765 may be implemented in a wirelessfashion, e.g., using wireless protocols and technologies, such as WiFi,WiMax, etc. The network 765 can also be a packet-switched network suchas a local area network, wide area network, metropolitan area network,Internet network, or other similar type of network environment. Thenetwork 765 may be a fixed wireless network, a wireless local areanetwork (LAN), a wireless wide area network (WAN) a personal areanetwork (PAN), a virtual private network (VPN), intranet or othersuitable network system and includes equipment for receiving andtransmitting signals.

If the computer 701 is a PC, workstation, intelligent device or thelike, the instructions in the memory 710 may further include a basicinput output system (BIOS) (omitted for simplicity). The BIOS is a setof essential software routines that initialize and test hardware atstartup, start the OS 711, and support the transfer of data among thehardware devices. The BIOS is stored in ROM so that the BIOS can beexecuted when the computer 701 is activated.

When the computer 701 is in operation, the processor 705 is configuredto fetch and execute instructions stored within the memory 710, tocommunicate data to and from the memory 710, and to generally controloperations of the computer 701 pursuant to the instructions.

In an exemplary embodiment, where the BPLs 110, 110′ of FIGS. 2 and 4are implemented in hardware, the methods described herein, such asprocesses 500 and 600 of FIGS. 5 and 6, can be implemented with any or acombination of the following technologies, which are each well known inthe art: a discrete logic circuit(s) having logic gates for implementinglogic functions upon data signals, an application specific integratedcircuit (ASIC) having appropriate combinational logic gates, aprogrammable gate array(s) (PGA), a field programmable gate array(FPGA), etc.

As will be appreciated by one skilled in the art, one or more aspects ofthe present invention may be embodied as a system, method or computerprogram product. Accordingly, one or more aspects of the presentinvention may take the form of an entirely hardware embodiment, anentirely software embodiment (including firmware, resident software,micro-code, etc.) or an embodiment combining software and hardwareaspects that may all generally be referred to herein as a “circuit,”“module” or “system”. Furthermore, one or more aspects of the presentinvention may take the form of a computer program product embodied inone or more computer readable medium(s) having computer readable programcode embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readablestorage medium. A computer readable storage medium may be, for example,but not limited to, an electronic, magnetic, optical, electromagnetic,infrared or semiconductor system, apparatus, or device, or any suitablecombination of the foregoing. More specific examples (a non-exhaustivelist) of the computer readable storage medium include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

Referring now to FIG. 8, in one example, a computer program product 800includes, for instance, one or more storage media 802, wherein the mediamay be tangible and/or non-transitory, to store computer readableprogram code means or logic 804 thereon to provide and facilitate one ormore aspects of embodiments described herein.

Program code, when created and stored on a tangible medium (includingbut not limited to electronic memory modules (RAM), flash memory,Compact Discs (CDs), DVDs, Magnetic Tape and the like is often referredto as a “computer program product”. The computer program product mediumis typically readable by a processing circuit preferably in a computersystem for execution by the processing circuit. Such program code may becreated using a compiler or assembler for example, to assembleinstructions, that, when executed perform aspects of the invention.

Embodiments include a system, method, and computer program product forinstruction filtering. The system includes memory configured to storeinstructions accessible by a processor, and the processor includes atracking array and a tracked instruction logic block. The processor isconfigured to perform a method including detecting, by the processor, atracked instruction in an instruction stream, and storing an instructionaddress of the tracked instruction in the tracking array based ondetecting and executing the tracked instruction. The method alsoincludes accessing the tracking array based on an address of instructiondata of a subsequently fetched instruction to locate the instructionaddress of the tracked instruction in the tracking array as anindication of the tracked instruction. The method further includesmarking, by the processor, instruction text of the subsequently fetchedinstruction to indicate that the subsequently fetched instruction is apreviously executed tracked instruction based on the indication of thetracked instruction from the tracking array. An action of the trackedinstruction logic block is prevented based on detecting the markedinstruction text.

In an embodiment, accessing of the tracking array is performed inparallel with accessing an instruction cache prior to instructiondecoding of the subsequently fetched instruction. In an embodiment, theprocessor of the system is further configured to select entries toremove from the tracking array randomly based on detecting trackedinstructions, and remove the randomly selected entries from the trackingarray. In an embodiment, the tracked instruction is a branch predictionpreload instruction, the tracking array is a branch prediction preloadtracking array, the tracked instruction logic block is branch predictionlogic, and the action is installation of a to be preloaded branchprediction to a branch predictor.

In an embodiment, the processor of the system is further configured tocheck a branch type of the to be preloaded branch prediction identifiedin the branch prediction preload instruction. Based on determining thatthe branch type is a multi-target branch, the prevented action ispreventing installation of the to be preloaded branch prediction to aleast recently used position of the branch predictor, and insteadforcing installation of the to be preloaded branch prediction into apredetermined set of the branch predictor. In an embodiment, the branchpredictor includes a branch target buffer and a branch target bufferpreload table, and the processor is configured to prevent movement of anentry in the branch target buffer preload table to the branch targetbuffer based on determining that the branch type of the entry is themulti-target branch. In an embodiment, the predetermined set of thebranch predictor is determined based on one or more of: a predictedbranch instruction address and a thread identifier.

In an embodiment, the processor of the system is further configured todetermine that a branch alias exists at a location in the branch targetbuffer preload table where a multi-target branch is predicted but doesnot exist. An indication of the branch alias is stored for the locationin the branch target buffer preload table. An entry at the location inthe branch target buffer preload table is invalidated based on detectingthe stored indication of the branch alias on a next multi-target branchprediction, and the stored indication of the branch alias is cleared.

Technical effects and benefits include instruction filtering.Embodiments recognize tracked instructions that have been previouslyexecuted and thereby prevent actions of the tracked instructions frombeing repeated upon subsequently encountering tracked instruction. Forexample, embodiments can prevent repeated preload installations into abranch predictor as well as additional instruction cache prefetches.Embodiments also handle preloading of branches with multiple targets andaliasing with a non-branch instruction.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of embodiments. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of embodiments have been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the embodiments in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the embodiments. Theembodiments were chosen and described in order to best explain theprinciples and the practical application, and to enable others ofordinary skill in the art to understand the embodiments with variousmodifications as are suited to the particular use contemplated.

Computer program code for carrying out operations for aspects of theembodiments may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider).

Aspects of embodiments are described above with reference to flowchartillustrations and/or schematic diagrams of methods, apparatus (systems)and computer program products according to embodiments. It will beunderstood that each block of the flowchart illustrations and/or blockdiagrams, and combinations of blocks in the flowchart illustrationsand/or block diagrams, can be implemented by computer programinstructions. These computer program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments. In this regard, each block in the flowchart or blockdiagrams may represent a module, segment, or portion of code, whichcomprises one or more executable instructions for implementing thespecified logical function(s). It should also be noted that, in somealternative implementations, the functions noted in the block may occurout of the order noted in the figures. For example, two blocks shown insuccession may, in fact, be executed substantially concurrently, or theblocks may sometimes be executed in the reverse order, depending uponthe functionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

What is claimed is:
 1. A computer-implemented method for branchprediction preload filtering, the method comprising: detecting, by aprocessor, a tracked instruction in an instruction stream; storing aninstruction address of the tracked instruction in a tracking array basedon detecting and executing the tracked instruction; accessing thetracking array based on an address of instruction data of a subsequentlyfetched instruction to locate the instruction address of the trackedinstruction in the tracking array as an indication of the trackedinstruction; marking, by the processor, instruction text of thesubsequently fetched instruction to indicate that the subsequentlyfetched instruction is a previously executed tracked instruction basedon the indication of the tracked instruction from the tracking array;and preventing an action of a tracked instruction logic block based ondetecting the marked instruction text.
 2. The computer-implementedmethod of claim 1, wherein accessing of the tracking array is performedin parallel with accessing an instruction cache prior to instructiondecoding of the subsequently fetched instruction.
 3. Thecomputer-implemented method of claim 1, further comprising: selectingentries to remove from the tracking array randomly based on detectingtracked instructions; and removing the randomly selected entries fromthe tracking array.
 4. The computer-implemented method of claim 1,wherein the tracked instruction is a branch prediction preloadinstruction, the tracking array is a branch prediction preload trackingarray, the tracked instruction logic block is branch prediction logic,and the action is installation of a to be preloaded branch prediction toa branch predictor.
 5. The computer-implemented method of claim 4,further comprising: checking a branch type of the to be preloaded branchprediction identified in the branch prediction preload instruction; andbased on determining that the branch type is a multi-target branch, theprevented action is preventing installation of the to be preloadedbranch prediction to a least recently used position of the branchpredictor, and instead forcing installation of the to be preloadedbranch prediction into a predetermined set of the branch predictor. 6.The computer-implemented method of claim 5, wherein the branch predictorfurther comprises a branch target buffer and a branch target bufferpreload table, and the method further comprises: preventing movement ofan entry in the branch target buffer preload table to the branch targetbuffer based on determining that the branch type of the entry is themulti-target branch.
 7. The computer-implemented method of claim 6,further comprising: determining that a branch alias exists at a locationin the branch target buffer preload table where a multi-target branch ispredicted but does not exist; storing an indication of the branch aliasfor the location in the branch target buffer preload table; andinvalidating an entry at the location in the branch target bufferpreload table based on detecting the stored indication of the branchalias on a next multi-target branch prediction, and clearing the storedindication of the branch alias.
 8. A computer program product for branchprediction preload filtering, the computer program product comprising: atangible storage medium readable by a processing circuit including abranch target buffer and storing instructions for execution by theprocessing circuit for performing a method comprising: detecting, by theprocessing circuit, a tracked instruction in an instruction stream;storing an instruction address of the tracked instruction in a trackingarray based on detecting and executing the tracked instruction;accessing the tracking array based on an address of instruction data ofa subsequently fetched instruction to locate the instruction address ofthe tracked instruction in the tracking array as an indication of thetracked instruction; marking, by the processing circuit, instructiontext of the subsequently fetched instruction to indicate that thesubsequently fetched instruction is a previously executed trackedinstruction based on the indication of the tracked instruction from thetracking array; and preventing an action of a tracked instruction logicblock based on detecting the marked instruction text.
 9. The computerprogram product of claim 8, further comprising: selecting entries toremove from the tracking array randomly based on detecting trackedinstructions; and removing the randomly selected entries from thetracking array.
 10. The computer program product of claim 8, wherein thetracked instruction is a branch prediction preload instruction, thetracking array is a branch prediction preload tracking array, thetracked instruction logic block is branch prediction logic, and theaction is installation of a to be preloaded branch prediction to abranch predictor.
 11. The computer program product of claim 10, furthercomprising: checking a branch type of the to be preloaded branchprediction identified in the branch prediction preload instruction; andbased on determining that the branch type is a multi-target branch, theprevented action is preventing installation of the to be preloadedbranch prediction to a least recently used position of the branchpredictor, and instead forcing installation of the to be preloadedbranch prediction into a predetermined set of the branch predictor. 12.The computer program product of claim 11, wherein the branch predictorfurther comprises a branch target buffer and a branch target bufferpreload table, and the method further comprises: preventing movement ofan entry in the branch target buffer preload table to the branch targetbuffer based on determining that the branch type of the entry is themulti-target branch; determining that a branch alias exists at alocation in the branch target buffer preload table where a multi-targetbranch is predicted but does not exist; storing an indication of thebranch alias for the location in the branch target buffer preload table;and invalidating an entry at the location in the branch target bufferpreload table based on detecting the stored indication of the branchalias on a next multi-target branch prediction, and clearing the storedindication of the branch alias.